-
Notifications
You must be signed in to change notification settings - Fork 286
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix: TAS assignment error #3937
Conversation
Signed-off-by: kerthcet <[email protected]>
Skipping CI for Draft Pull Request. |
/test |
@kerthcet: The
Use In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |
/test all |
✅ Deploy Preview for kubernetes-sigs-kueue canceled.
|
Signed-off-by: kerthcet <[email protected]>
/test all |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please add a unit test in scheduler_test.go
TestScheduleForTAS
for the problematic scenario.
for k, v := range singlePodRequest { | ||
usage[k] = v * int64(domain.state) | ||
} | ||
s.addUsage(domain.id, usage) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I believe this will work fine for now as TAS is not combined with cohorts, and so only one workload is considered in each scheduling cycle on the snapshot. However, this will not work well when we start supporting cohorts - in that case usage coming from the assignment phase for a workload that is de-prioritized in a cohort will consume the capacity, but scheduler should operate on "clean" capacity.
One way to go about it in the future would be to remember usage coming from "Inflight" PodSets, and clean it at the end of the assignment phase, before the actual scheduling phase.
Since I don't see it problematic in the current assumptions (no cohorts) I believe a TODO with #3761 is sufficient.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Will add tests later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you mean when having time, or in a follow up PR? My preference would be to add the test in this PR.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I mean when I have time later, have codes without tests is terrible.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure, I would like to include the fix in 0.10.1, and tentatively planning next week. Do you think you would add the test by then? I can also help to write it
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
will do this weekend
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we have a test that covers a case where request topology is not the lowest level? E.g. the lowest level is hostname and job request (and can only fit in) a block? I have concerns if it's gonna work if the requested level is not the lowest one, since s.addUsage()
method add usage only to leaves in the topology tree structure
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Make sense, but I think it still works because we'll traverse down the domains level by level until the lowest ones, which means we'll always get the lowest domains in addUsage()
. Added the tests. PTAL.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you adjust the test so the topology is made out of three levels. And then add also another podset that should make a workload not fit within requested topology? I am afraid this usage may not be counted if it's not at the lowest level, so this is what I wanted to test
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
After second consideration I think, you're actually right and the usage will be tracked correctly. Thanks for adding the test
Test added, PTAL.
|
Signed-off-by: kerthcet <[email protected]>
Signed-off-by: kerthcet <[email protected]>
/lgtm |
LGTM label has been added. Git tree hash: 443aefcbe7ebde6a093ee0181c3a61236f54ce8c
|
/approve |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: kerthcet, mimowo The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
/cherry-pick release-0.10 release-0.9 |
@mimowo: once the present PR merges, I will cherry-pick it on top of In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |
@mimowo: new pull request created: #3970 In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |
Proposal:
|
What type of PR is this?
/kind bug
What this PR does / why we need it:
Which issue(s) this PR fixes:
Fixes #3887
Special notes for your reviewer:
Does this PR introduce a user-facing change?